IBIS Macromodel Task Group

Meeting date: 19 June 2018

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Stephen Slater
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:            Randy Wolff
                            * Justin Butterfield
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
    
The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad noted the we have a meeting scheduled for July 3rd, and we may want to
  consider cancelling it if many people are away that week.  He said we will
  decide at the next meeting on June 26th.

- Michael M. noted that he had some questions related to the BCI BIRD147.6 and
  repeaters.  He said he would like to discuss them time permitting.

-------------
Review of ARs:

- Randy to update the enhanced C_comp Model BIRD draft.
  - Done.

- Michael M. to send his "Enabling [Rgnd] and [Rpower] for Input Model_type"
  v2 for posting.
  - Done.

- Arpad to send his "Questions about Usage Out parameters" for posting.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the June 12
meeting.  Mike L. moved to approve the minutes.  Michael M. seconded the motion. There were no objections.

-------------
New Discussion:

- Arpad asked if Walter wanted to discuss item #9 on the agenda, "Walter's
  drawing with Vladimir's comments."  Walter said this topic no longer needed to
  be discussed, and the item could be removed from the agenda.

Enabling [Rgnd] and [Rpower] for Input Model_type (v2):
- Discussion:  Michael M. noted that the only change in this version was an
  editorial cleanup to ensure "Rgnd" was used ("Rground" had been mistakenly
  used in several places in v1).  Curtis asked about the statement, "The
  C_comp subparameter is required for [Model]s using any or all of these
  keywords..."  Curtis noted that it is already stated elsewhere in the spec.
  that C_comp is required for all [Model]s.  Michael M. agreed and said he had
  restated it in this location to make it absolutely clear that you still need
  C_comp even if you're using Rac and Cac.

  Michael M. moved that the ATM recommend draft v2 be submitted to the Open
  Forum as a BIRD.  Walter seconded.  There were no objections.

  Arpad asked if Michael M. wanted this to go into IBIS 7.0 or a later version.
  Michael M. said he had no real preference.  If it went into 7.0 that was
  fine, but it was not a burning need so it shouldn't hold up 7.0.

Usage Out and Format:
- Discussion:  Arpad noted that during the previous meeting's discussion he
  thought there was consensus that the PAM4_LowerThreshold Usage Out example on
  (pg. 235-236) needed to be fixed.  He asked if the group thought this needed
  a BIRD or could be handled as an editorial task.  Radek said he thought the
  Editorial Task Group could handle it, as it's an example and simply needs to
  have the Value added to all three thresholds.  Bob agreed.  Bob moved to have
  Mike L. update the known issues list for IBIS 6.1 to include this fix.
  Curtis seconded.  There were no objections.

  Arpad moved on to technical issues from the previous meeting's discussion of
  his presentation.  He asked if we needed to revisit the topic of single-valued
  Value for Usage Out to make it clearer what the EDA tool should do.  For
  example, should we:
    1. Explicitly state that the value in the .ami file should be ignored.
    2. Or perhaps the value should be used as a default if the model doesn't
       return a value (Arpad referred to the example he mentioned in the last
       meeting in which a model had not returned a value for a particular Out
       parameter.  This model's behavior was not legal according to the
       current language in the spec.)

  Arpad said he understood how the values for Range, Steps, List, etc., might
  allow the EDA tool to do some sanity checking of the value returned by the
  model.  But for the single-valued Value Format, what's the point of having a
  value in the .ami file at all?  Radek said that the Format is required so the
  EDA tool knows what type of data to expect from the model.  If the Format
  happens to be a single Value, then it is just a place holder in the .ami file.

  Walter noted that he agreed that it doesn't make a lot of sense to provide a
  Value for an Out parameter.  However, he said at this point we are stuck with
  it and it's not really causing any trouble.  Walter suggested we simply fix
  the example and move on.
 
  Curtis asked if Arpad wanted to simply explicitly state that the Value is
  ignored.  This would leave it there as a place holder for the parser, and
  would avoid introducing any "interdependent rules" that Bob had noted we
  try to avoid (i.e. avoid saying "Format is required unless it's a Value for a
  Usage Out" parameter).  Walter said the parser changes would be trivial
  anyway.  Walter said if someone really wanted to take the time to write up a
  BIRD to address this question, they could do it.

  Arpad said he might write up a BIRD, and that he had raised the issue to see
  if there was consensus that we should clarify this issue.  Walter said that he
  didn't think it was necessary.  Curtis agreed with Walter.

BCI BIRD147.6 and repeaters:
- Discussion:  Michael M. noted one editorial issue in which language in the
  BIRD states "...if the channel does not have automatic link training
  capabilities."  He noted that we should probably refer to endpoint devices,
  not channels, as having link training capabilities.  We generally refer to the
  channel as the passive interconnect.

  Michael M. noted the following sentence from the BIRD:
     "Channels with repeaters will require that the downstream Rx be able to
      control all upstream equalization."
  and asked the following questions:

  1.  How do we define the repeater interaction for BCI purposes?
      We may want to spell out in the form of a table what legal and required
      interactions there are between BCI AMI keywords and repeaters.
  2.  We say something about "repeaters" specifically, but that includes
      redrivers and retimers.  Are we saying that redriver vendors have to
      create optimization BCI file sequences even if their actual devices don't
      do that?  A redriver is a device that does not necessarily interact with
      other devices for setting up adaptive equalization.  Do repeaters have to
      participate in BCI even if real devices wouldn't?
  3.  The sentence implies that the final endpoint Rx has to optimize the
      equalization of all the upstream channels.  Are we really referring to
      entire link?
      PCIe 4.0, for example, can have two retimers in a link.  So one could have
      three distinct channels for a PCIe 4.0 link.  Are we saying the final
      endpoint determines the equalization for everything in the link or just
      the immediate upstream channel.

  Michael M. noted that we might need a table with statements about what is
  expected, required, or illegal when BCI and repeaters interact.

  Walter noted that repeater BCI interaction might not have been fully thought
  out originally.  However, he noted that he thought this could all be covered
  in the specific protocols.  We can define a protocol that says the downstream
  Rx optimizes everybody, or it only optimizes the previous Tx.  He noted that
  for a retimer it's silly for an Rx to do anything other than optimize its
  immediate predecessor.  It's really only for a redriver that it becomes a
  question.  Walter said the hope was that when people began to implement BCI
  models they would bring up these issues, as Michael was.

  Michael M. agreed most of it could probably be handled within the protocol.
  However, he noted there are some implied rules about having certain keywords
  exist on both the Tx and Rx end or the two devices can't talk.  We have some
  bare minimum rules for Tx and Rx requirements, and we might need to extend
  that to cover the repeater case.
 
  Mike L. noted that at one point Ambrish had described how it would be handled
  for redrivers.  He had noted that it was really important that GetWaves were
  called in the proper order along the channel, because each device could write
  things into the BCI file, and the final Rx could then see all the participants
  in the channel.

- Michael M.: Motion to adjourn.
- Justin: Second.
- Arpad: Thank you all for joining.

AR: Michael M. to submit his "Enabling [Rgnd] and [Rpower] for Input Model_type"
    v2 to the Open Forum as a BIRD (done - BIRD195).
AR: Arpad to send an email to the Open Forum noting that the ATM had voted to
    submit BIRD195.
AR: Mike L. to update the IBIS 6.1 known issues list to include adding Value
    entries to the PAM4 thresholds Usage Out example on pg. 235-236.

-------------
Next meeting: 26 June 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
